UML 2 Activity and Action Models Part 6: Structured Activities

This is the sixth in a series introducing the activity model in the Unified Modeling Language, version 2 (UML 2), and how it integrates with the action model [1]. The first article gives an overview of activities and actions [2], while the next four cover models typically used for graphical flow languages. This one describes models for languages that usually have textual presentations. It covers structured nodes for sequencing, conditionals, loops, and expansion regions for operating on collections, as well as exception handlers, variables, and action pins. Two of the most common process notation styles are: • Graphical notations usually support less restricted patterns of control flow. They normally use data flow rather than variables to pass data between actions. • Textual notations are usually designed for well-nested control, even if they support non-local control flow in exceptional cases. They typically use variables to pass data between actions, rather than data flow. Ideally, there would be a single underlying model for these, 1 but to simplify translation from notation to repository, UML activities have models for both presentation styles, informally called flow and structure models. Unfortunately, the models are not independent, because the structured elements mainly address control, still requiring flow 1 Structured and flow models are equivalent as long as the value of each variable in the structured model is only set once, and queuing is not used in the flow model. With a single underlying model, the various notations could be easily compared and integrated. However, in general this requires complicated translations between notation and repository. It may be easy enough when diagrams are translated all at once, but more difficult when translated incrementally as the modeler edits the notation. Mappings from notation to model also affect monitoring and debugging execution at the level of the original notation. In the long run it can be expected that model compilation and execution visualization will become as sophisticated as they are in convention languages, and translations between many notations and a single underlying model more routine.